CLN: use RangeIndex._range instead of RangeIndex._start etc. #26578
Conversation
topper-123
force-pushed
the
clean_RangeIndex
branch
from
8f431bd to
6b15312
Compare
Codecov Report
@@ Coverage Diff @@
## master #26578 +/- ##
==========================================
- Coverage 41.79% 41.67% -0.13%
==========================================
Files 174 174
Lines 50643 50617 -26
==========================================
- Hits 21168 21094 -74
- Misses 29475 29523 +48
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #26578 +/- ##
==========================================
- Coverage 91.84% 91.84% -0.01%
==========================================
Files 174 174
Lines 50643 50624 -19
==========================================
- Hits 46515 46494 -21
- Misses 4128 4130 +2
Continue to review full report at Codecov.
|
| .. deprecated:: 0.25.0 | ||
| Use ._range.start or .start instead. | ||
| """ | ||
| return self._range.start |
There was a problem hiding this comment.
Unfortunately, fast_parquet uses _start etc. which I hadn't predicted, when I started this PR. So this proposes deprecating the attributes _start, _stop and _step, and removing them in 1.0.
Thuis can be bit of a nuisance for upstream maintainers, so don't know if there's opposition to this, but this PR has several benefits also, so there's a trade-off.
|
Some problems, closing temporqrily. |
git diff upstream/master -u -- "*.py" | flake8 --diffMake RangeIndex use python's
rangeinternally, rather than the three scalars_start,_stopand_step.Python3's
rangehas several nice properties, that were not available inxrangein Python2. For example it's sliceable, and has.indexandcountand various magic methods. These can be used in Pandas, rather than maintaining Pandas-specific code, offering cleaner code and possibly faster operations.